Packet data traffic is growing very quickly in mobile communications networks or mobile operator networks; in many cases, it grows faster than a rate at which operators can expand network capacity. This leads to more frequent occurrences of congestion of a radio access network (RAN). Congestion may occur when data traffic exceeds a data traffic capacity of RAN. Also, new services appear which may lead to a situation when a new Quality of Experience requirement has to be introduced into the network. In this situation, operators need efficient and flexible tools by which they can control sharing of the bottleneck of RAN capacity to increase the Quality of Experience.
Recently, in the context of the 3rd Generation Partnership Project (3GPP) User plane congestion management (UPCON) work item, a new solution has been put forward which utilizes congestion feedback from the RAN to the CN (Core Network), see 3GPP Technical Report (TR) 23.705, version 0.10.0 of May 2014, section 6.1. When the RAN indicates congestion to the CN, the CN can take actions to mitigate the congestion, such as limiting some classes of traffic or request to delay some other classes of traffic.
The RAN Operation and Maintenance (OAM) systems typically provide information based on which an operator may derive when congestion takes place. Such information can include, e.g., an amount of packet loss, packet delay, traffic throughput, air interface utilization, a number of connected users, a number of connected users with non-empty buffers, etc. An operator may configure thresholds on one of these metrics or on a combination of these metrics to determine when a state of congestion is considered, i.e., when congestion becomes significant. It is also possible for a operator to define multiple levels of congestion using a combination of these metrics so that the actions for congestion mitigation can be based on the level of congestion.
Current RAN OAM systems operate on a per-cell level or even on lower spatial granularity. I.e., determining congestion may be performed on a per-cell basis or may be performed for a group of cells, such as cells belonging to the same eNodeB (evolved Node B) for mobile communications networks according to the Long Term Evolution (LTE) standard as specified by the 3GPP, or cells belonging to the same Service Area for mobile communications networks according to the Universal Mobile Telecommunications System (UMTS) standard as specified by the 3GPP. In order for the CN to take an appropriate mitigation action, the CN typically needs to determine which mobile entities (UEs) are located in a given cell. Hence, the list of affected UEs needs to be determined for the cells which are considered congested based on OAM data.
One solution for OAM based congestion reporting is documented in solution 1.5.5 (also called off-path solution) in section 6.1.5.5 of 3GPP TR 23.705, version 0.10.0 of May 2014 which suggests the interface Nq for this purpose. The Nq interface is defined between a network entity labeled RAN Congestion Awareness Function (RCAF) and the Mobility Management Entity (MME). The RCAF receives a congestion report including RAN congestion related data from the RAN OAM system on a per cell spatial granularity or at a lower granularity. Then, using the Nq interface, the RCAF queries the MME to supply the list of UEs per cell.
A similar approach is suggested for the UMTS case, using Nq′ interface from the RCAF to the Serving GPRS Support Node (SGSN). However, there is a difference for UMTS since the RAN can already be aware of the identities of UEs as, e.g., the International Mobile Subscriber Identity (IMSI) can be sent to the Radio Network Controller (RNC). The RAN OAM collects these IMSIs and the RAN OAM then supplies the list of UEs identified by IMSI that are affected by congestion to the RCAF. Hence, in such a UMTS scenario, the list of UEs affected by congestion are known to the RCAF without contacting the SGSN over the Nq′ interface.
Once the RCAF node has collected information about the set of UEs affected by congestion, it notifies the Policy and Charging Rules Function (PCRF) about the congestion level of the affected UEs by sending congestion information. Here, the UEs may be identified by a UE identifier such as the IMSI. The Np interface is defined between the RCAF and the PCRF for this purpose. As described in 3GPP TR 23.705, version 0.10.0 of May 2014, section 6.1.6, the PCRF can then take actions to mitigate the congestion e.g., by limiting the traffic in an enforcement node such as a Packet Data Network Gateway (PGW) or Traffic Detection Function (TDF), or notifying the Application Function (AF) to limit or delay the traffic, etc.
Current techniques typically require a comparably large number of messages including congestion information to be sent from the RCAF to the PCRF via the Np interface. This may itself cause significant traffic on the Np interface. In case a given cell becomes congested, usually a larger number of UEs connected to this cell becomes affected by congestion; in turn, a congestion status for this number of UEs typically changes together. Therefore, excessive signaling traffic on the Np interface may result, requiring expensive and complex upgrades of the PCRF and/or the RCAF to handle such situations. Excessive signaling on the Np interface can render operation of the mobile communications network unstable, especially when a significant part of the mobile communications network suffers from congestion.